home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1993 / Internet Info CD-ROM (Walnut Creek) (1993).iso / security / tcp_wrapper.txt < prev    next >
Text File  |  1992-08-31  |  25KB  |  727 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7.  
  8.  
  9.  
  10.                         TCP WRAPPER
  11.        Network monitoring, access control, and booby
  12.                            traps.
  13.  
  14.  
  15.                        Wietse Venema
  16.  
  17.              Mathematics and Computing Science
  18.              Eindhoven University of Technology
  19.                       The Netherlands
  20.                    wietse@wzv.win.tue.nl
  21.  
  22.  
  23.  
  24.  
  25.  
  26.                           Abstract
  27.  
  28. This paper presents a simple tool  to  monitor  and  control
  29. incoming  network  traffic.   The tool has been successfully
  30. used for shielding off systems and for detection of  cracker
  31. activity. It has no impact on legal computer users, and does
  32. not require any change to existing systems software or  con-
  33. figuration files.  The tool has been installed world-wide on
  34. numerous UNIX systems without any source code change.
  35.  
  36.  
  37.  
  38. 1.  Our pet.
  39.  
  40. The story begins about two years  ago.  Our  university  was
  41. under heavy attack by a Dutch computer cracker who again and
  42. again managed to acquire root privilege.  That  alone  would
  43. have  been  nothing more than an annoyance, but this indivi-
  44. dual was  very  skilled  at  typing  the  following  command
  45. sequence:
  46.  
  47.         rm -rf /
  48.  
  49. For those with no UNIX experience: this command,  when  exe-
  50. cuted at a sufficiently high privilege level (like root), is
  51. about as destructive as the MS-DOS format command.  Usually,
  52. the  damage  could  be repaired from backup tapes, but every
  53. now and then people still lost a large amount of work.
  54.  
  55. Though  we  did  have  very  strong  indications  about  the
  56. cracker's  identity  I cannot disclose his name. We did give
  57. him a nickname, though: "our pet"1.
  58. _________________________
  59.  
  60. 1.   Like hond (dog), kat (cat), and muis (mouse).
  61.  
  62.  
  63.  
  64.                        July 15, 1992
  65.  
  66.  
  67.  
  68.  
  69.  
  70.                            - 2 -
  71.  
  72.  
  73. 2.  The cracker is watching us.
  74.  
  75. The destructive behavior of the cracker made it very hard to
  76. find  out  what  was going on: the rm -rf removed all traces
  77. very effectively. One late night I noticed that the  cracker
  78. was  watching us over the network. He did this by frequently
  79. making contact with our finger network service, which  gives
  80. information  about  users.   Services  such as finger do not
  81. require a password, and almost never keep a record of  their
  82. use.  That  explains  why  all  his  fingering  activity had
  83. remained unnoticed.
  84.  
  85. The natural reaction would be to shut down the  finger  net-
  86. work  service.   I  decided,  however, that it would be more
  87. productive to maintain the service and to find out where the
  88. finger requests were coming from.
  89.  
  90. 3.  A typical UNIX TCP/IP networking implementation.
  91.  
  92. In order to explain the problem  and  its  solution  I  will
  93. briefly  summarize  a  typical  UNIX  implementation  of the
  94. TCP/IP network services.  Experts will  forgive  me  when  I
  95. make a few simplifications.
  96.  
  97. Almost every application of the TCP/IP protocols is based on
  98. a  client-server  model.  For example, when someone uses the
  99. telnet command to connect to a host, a telnet server process
  100. is  started  on the target host. The server process connects
  101. the user to a login process.  A few examples  are  shown  in
  102. table 1.
  103.  
  104.               client   server    application
  105.               ________________________________
  106.               telnet   telnetd   remote login
  107.               ftp      ftpd      file transfer
  108.               finger   fingerd   show users
  109.               systat   systatd   show users
  110.  
  111.  
  112.  
  113.      Table 1.  Examples of TCP/IP  client-server  pairs  and
  114.      their applications.
  115.  
  116. The usual approach is to run one daemon process  that  waits
  117. for  all  kinds  of incoming network connections. Whenever a
  118. connection is established this daemon (usually called inetd)
  119. runs  the appropriate server program and goes back to sleep,
  120. waiting for other connections.
  121.  
  122. 4.  The "tcp wrapper" trick.
  123.  
  124. Back to the original problem: how to get  the  name  of  the
  125. host that the cracker was spying from.  At first sight, this
  126. would require changes to existing network  software.   There
  127. were a few problems, though:
  128.  
  129.  
  130.                        July 15, 1992
  131.  
  132.  
  133.  
  134.  
  135.  
  136.                            - 3 -
  137.  
  138.  
  139.  
  140.  
  141.                                            ---------
  142.             -----------------    (ftp)-----|   i   |
  143.      user---| telnet client |----(telnet)--|   n   |
  144.             -----------------     .        |   e   |
  145.                                   .        |   t   |
  146.                                  (finger)--|   d   |
  147.                                            ---------
  148.  
  149.      Figure 1.  The inetd daemon process listens on the ftp,
  150.      telnet  etc.  network ports and waits for incoming con-
  151.      nections. The figure shows that a user has connected to
  152.      the telnet port.
  153.  
  154.             -----------------      -----------------    ---------
  155.      user---| telnet client |------| telnet server |----| login |
  156.             -----------------      -----------------    ---------
  157.  
  158.      Figure 2.  The  inetd  process  has  started  a  telnet
  159.      server  process  that connects the user to a login pro-
  160.      cess.  Meanwhile, inetd waits for other  incoming  con-
  161.      nections.
  162.  
  163. o    We did not have a source license for the Ultrix,  SunOS
  164.      and  other UNIX implementations on our systems. And no,
  165.      we did not have those sources either.
  166.  
  167. o    The Berkeley network sources (from which  most  of  the
  168.      commercial  UNIX  TCP/IP  network  implementations  are
  169.      derived) were  available,  but  porting  these  to  our
  170.      environments would require an unknown amount of work.
  171.  
  172. Fortunately, there  was  a  simple  solution  that  did  not
  173. require any change to existing software, and that turned out
  174. to work on all UNIX systems that I tried it  on.  The  trick
  175. was to make a swap:  move the vendor-provided network server
  176. programs to another place, and install a trivial program  in
  177. the original place of the network server programs.  Whenever
  178. a connection was made, the trivial program would just record
  179. the  name of the remote host, and then run the original net-
  180. work server program.
  181.  
  182.  
  183.             -----------------      -----------------
  184.      user---| telnet client |------|  tcp wrapper  |---> logfile
  185.             -----------------      -----------------
  186.  
  187.      Figure 3.  The original telnet server program has  been
  188.      moved to some other place, and the tcp wrapper has tak-
  189.      en its place. The wrapper logs the name of  the  remote
  190.      host to a file.
  191.  
  192.  
  193.  
  194.  
  195.  
  196.                        July 15, 1992
  197.  
  198.  
  199.  
  200.  
  201.  
  202.                            - 4 -
  203.  
  204.  
  205.  
  206.  
  207.             -----------------      -----------------    ---------
  208.      user---| telnet client |------| telnet server |----| login |
  209.             -----------------      -----------------    ---------
  210.  
  211.      Figure 4.  The tcp wrapper program has started the real
  212.      telnet server and no longer participates. The user can-
  213.      not notice any difference.
  214.  
  215. The first tcp wrapper version was just a few lines  of  code
  216. that  I  had  carefully  copied from some old network daemon
  217. source.  Because it did not exchange  any  information  with
  218. the client or server processes, the same tcp wrapper version
  219. could be used for many types of network service.
  220.  
  221. Although I could install the wrapper only on a dozen systems
  222. it  was  an immediate success. Figure 5 gives an early exam-
  223. ple.
  224.  
  225.  
  226.      May 21 14:06:53 tuegate: systatd: connect from monk.rutgers.edu
  227.      May 21 16:08:45 tuegate: systatd: connect from monk.rutgers.edu
  228.      May 21 16:13:58 trf.urc: systatd: connect from monk.rutgers.edu
  229.      May 21 18:38:17 tuegate: systatd: connect from ap1.eeb.ele.tue.nl
  230.      May 21 23:41:12 tuegate: systatd: connect from mcl2.utcs.utoronto.ca
  231.      May 21 23:48:14 tuegate: systatd: connect from monk.rutgers.edu
  232.  
  233.      May 22 01:08:28 tuegate: systatd: connect from HAWAII-EMH1.PACOM.MIL
  234.      May 22 01:14:46 tuewsd:  fingerd: connect from HAWAII-EMH1.PACOM.MIL
  235.      May 22 01:15:32 tuewso:  fingerd: connect from HAWAII-EMH1.PACOM.MIL
  236.      May 22 01:55:46 tuegate: systatd: connect from monk.rutgers.edu
  237.      May 22 01:58:33 tuegate: systatd: connect from monk.rutgers.edu
  238.      May 22 02:00:14 tuewsd:  fingerd: connect from monk.rutgers.edu
  239.      May 22 02:14:51 tuegate: systatd: connect from RICHARKF-TCACCIS.ARMY.MIL
  240.      May 22 02:19:45 tuewsd:  fingerd: connect from RICHARKF-TCACCIS.ARMY.MIL
  241.      May 22 02:20:24 tuewso:  fingerd: connect from RICHARKF-TCACCIS.ARMY.MIL
  242.  
  243.      May 22 14:43:29 tuegate: systatd: connect from monk.rutgers.edu
  244.      May 22 15:08:30 tuegate: systatd: connect from monk.rutgers.edu
  245.      May 22 15:09:19 tuewse:  fingerd: connect from monk.rutgers.edu
  246.      May 22 15:14:27 tuegate: telnetd: connect from cumbic.bmb.columbia.edu
  247.      May 22 15:23:06 tuegate: systatd: connect from cumbic.bmb.columbia.edu
  248.      May 22 15:23:56 tuewse:  fingerd: connect from cumbic.bmb.columbia.edu
  249.  
  250.      Figure 5.  Some of the first  cracker  connections  ob-
  251.      served with the tcp wrapper program. Each connection is
  252.      recorded with: time stamp, the name of the local  host,
  253.      the  name  of the requested service (actually, the net-
  254.      work server process name), and the name of  the  remote
  255.      host.  The examples show that the cracker not only used
  256.      dial-up terminal servers  (such  as  monk.rutgers.edu),
  257.      but  also  that  he had broken into military (.MIL) and
  258.      university (.EDU) computer systems.
  259.  
  260.  
  261.  
  262.                        July 15, 1992
  263.  
  264.  
  265.  
  266.  
  267.  
  268.                            - 5 -
  269.  
  270.  
  271. The cracker literally bombarded our systems with finger  and
  272. systat  requests.   These  allowed him to see who was on our
  273. systems. Every now and then he would make a  telnet  connec-
  274. tion,  presumably  to  make  a  single  login attempt and to
  275. disconnect immediately, so that no "repeated login  failure"
  276. would be reported to the systems console.
  277.  
  278. Thus, while the cracker thought he was spying on us we could
  279. from  now  on see where he was. This was a major improvement
  280. over the past, when we  only  knew  something  had  happened
  281. after he had performed his rm -rf act.
  282.  
  283. My initial fear was that we  would  be  swamped  by  logfile
  284. information  and  that there would be too much noise to find
  285. the desired signal.  Fortunately, the cracker  was  easy  to
  286. recognize:
  287.  
  288. o    He often worked at night, when there  is  little  other
  289.      activity.
  290.  
  291. o    He would often make a series of connections to a number
  292.      of  our  systems.   By  spreading his probes he perhaps
  293.      hoped to hide his activities.  However, by merging  the
  294.      logs from several systems it was actually easier to see
  295.      when the cracker was in the air.
  296.  
  297. o    No-one else used the systat service.
  298.  
  299. In the above example, one of  the  systat  connections  came
  300. from  a  system  within  our university: ap1.eeb.ele.tue.nl,
  301. member of a ring of Apollo workstations. Attempts  to  alert
  302. their  system administrator were in vain: one week later all
  303. their file systems were wiped out. The backups were  between
  304. one and two years old, so the damage was extensive.
  305.  
  306. 5.  First extension: access control.
  307.  
  308. I will not go into a discussion on  the  pros  and  cons  of
  309. publicly-accessible  terminal servers with world-wide inter-
  310. net access, but it is clear that any traces that  originated
  311. from  such  a  system  would be useless for our purposes: we
  312. would need cooperation from  US  and  Dutch  telephone  com-
  313. panies,  from  the administrators of those terminal servers,
  314. and so on.
  315.  
  316. The best thing to do was to  refuse  connections  from  open
  317. terminal  servers,  so  that the cracker could reach us only
  318. after breaking into a regular user  account.  Our  hope  was
  319. that  the  would  leave some useful traces, so that we would
  320. get to know him a little better.
  321.  
  322. I built a  simple  access-control  mechanism  into  the  tcp
  323. wrapper.   Whenever  a  connection  from  a  terminal server
  324. showed up in the logs, all traffic from that system would be
  325.  
  326.  
  327.  
  328.                        July 15, 1992
  329.  
  330.  
  331.  
  332.  
  333.  
  334.                            - 6 -
  335.  
  336.  
  337. blocked  on  our  side,  and  we  would  ask the responsible
  338. administrators to do the same on their  side.  Sometimes  it
  339. even  worked.   Figure  6  gives  a  snapshot of our access-
  340. control files.
  341.  
  342.  
  343.      /etc/hosts.allow:
  344.  
  345.          in.ftpd: ALL
  346.  
  347.      /etc/hosts.deny:
  348.  
  349.          ALL: terminus.lcs.mit.edu hilltop.rutgers.edu monk.rutgers.edu
  350.          ALL: comserv.princeton.edu lewis-sri-gw.army.mil
  351.          ALL: ruut.cc.ruu.nl 131.211.112.44
  352.          ALL: tip-gsbi.stanford.edu
  353.          ALL: tip-quada.stanford.edu
  354.          ALL: s101-x25.stanford.edu
  355.          ALL: tip-cdr.stanford.edu
  356.          ALL: tip-cromemaa.stanford.edu
  357.          ALL: tip-cromembb.stanford.edu
  358.          ALL: tip-forsythe.stanford.edu
  359.  
  360.      Figure 6.  Sample access-control files. The first  file
  361.      describes  which  (service,  host) combinations are al-
  362.      lowed. In this example, the ftp file  transfer  service
  363.      is granted to all systems.
  364.  
  365.      The second file describes which of the remaining  (ser-
  366.      vice,  host) combinations are disallowed. In this exam-
  367.      ple, an ever-growing list of open terminal  servers  is
  368.      refused access.
  369.  
  370.      (service, host) pairs that are not matched  by  any  of
  371.      the access-control files are always allowed.
  372.  
  373.  
  374. 6.  Our turn: watching the cracker.
  375.  
  376. Now  that  the  cracker  could  no  longer  attack  us  from
  377. publicly-accessible terminal servers, all he could do was to
  378. break into a regular user account and  proceed  from  there.
  379. That  is  exactly what he did. The next step was to find out
  380. what user accounts were involved.
  381.  
  382. I quickly cobbled together something that  would  consult  a
  383. table  of  "bad"  sites  and  send a finger and systat probe
  384. whenever one made a connection to us. Now we would  be  able
  385. to watch the cracker just like he had been watching us.
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394.                        July 15, 1992
  395.  
  396.  
  397.  
  398.  
  399.  
  400.                            - 7 -
  401.  
  402.  
  403. During the next  months  I  identified  several  broken-into
  404. accounts.  Each  time  I  would  send a notice to the system
  405. administrators, and a copy to CERT2 to keep them informed of
  406. our progress.
  407.  
  408.  
  409.      Jan 30 04:55:09 tuegate: telnetd: connect from guzzle.Stanford.EDU
  410.      Jan 30 05:10:02 svin01:  fingerd: connect from guzzle.Stanford.EDU
  411.      Jan 30 05:17:57 svin01:  fingerd: connect from guzzle.Stanford.EDU
  412.      Jan 30 05:18:24 svin01:  fingerd: connect from guzzle.Stanford.EDU
  413.      Jan 30 05:18:34 svin01:  fingerd: connect from guzzle.Stanford.EDU
  414.      Jan 30 05:18:38 svin01:  fingerd: connect from guzzle.Stanford.EDU
  415.      Jan 30 05:18:44 svin01:  fingerd: connect from guzzle.Stanford.EDU
  416.      Jan 30 05:21:03 svin01:  fingerd: connect from guzzle.Stanford.EDU
  417.      Jan 30 05:24:46 tuegate: systatd: connect from guzzle.Stanford.EDU
  418.      Jan 30 05:27:20 svin01:  fingerd: connect from gloworm.Stanford.EDU
  419.      Jan 30 05:33:33 svin01:  telnetd: connect from guzzle.Stanford.EDU
  420.      Jan 30 05:33:38 svin01:  telnetd: connect from guzzle.Stanford.EDU
  421.      Jan 30 05:33:41 svin01:  telnetd: connect from guzzle.Stanford.EDU
  422.      Jan 30 05:33:50 svin01:  ftpd:    connect from guzzle.Stanford.EDU
  423.      Jan 30 05:33:58 svin01:  fingerd: connect from math.uchicago.edu
  424.      Jan 30 05:34:08 svin01:  fingerd: connect from math.uchicago.edu
  425.      Jan 30 05:34:54 svin01:  fingerd: connect from math.uchicago.edu
  426.      Jan 30 05:35:16 svin01:  fingerd: connect from guzzle.Stanford.EDU
  427.      Jan 30 05:35:36 svin01:  fingerd: connect from guzzle.Stanford.EDU
  428.  
  429.      Figure 7.  A burst of network activity, most of it from
  430.      Stanford.
  431.  
  432.  
  433.      Wed Jan 30 05:10:08 MET 1991
  434.  
  435.      [guzzle.stanford.edu]
  436.      Login name: adrian                      In real life: Adrian Cooper
  437.      Directory: /u0/adrian                   Shell: /phys/bin/tcsh
  438.      On since Jan 29 19:30:18 on ttyp0 from tip-forsythe.Sta
  439.      No Plan.
  440.  
  441.      Figure 8.  A reverse finger result, showing  that  only
  442.      one user was logged on at the time.
  443.  
  444.  
  445. The examples in figures 7 and 8 show activity from a  single
  446. user  who  was  logged in on the system guzzle.Stanford.EDU.
  447. The account name is adrian, and the login came  in  via  the
  448. terminal  server tip-forsythe.Stanford.EDU.  Because of that
  449. terminal server I wasn't too optimistic. Things  turned  out
  450. to be otherwise.
  451. _________________________
  452.  
  453. 2.   Computer Emergency Response Team, an organization  that
  454.      was  called  into existence after the Internet worm in-
  455.      cident in 1988.
  456.  
  457.  
  458.  
  459.  
  460.                        July 15, 1992
  461.  
  462.  
  463.  
  464.  
  465.  
  466.                            - 8 -
  467.  
  468.  
  469. CERT suggested that I contact  Stephen  Hansen  of  Stanford
  470. university.   He  had  been  monitoring the cracker for some
  471. time, and his logs gave an excellent insight  into  how  the
  472. cracker  operated.  The cracker did not use any black magic:
  473. he knew many system software bugs, and was  very  persistent
  474. in  his  attempts to get superuser privilege. Getting into a
  475. system was just a matter of finding an account with  a  weak
  476. password.
  477.  
  478. For several months the cracker used  Stanford  as  his  home
  479. base  to  attack a large number of sites. One of his targets
  480. was research.att.com,  the  AT&T  Bell  labs  gateway.  Bill
  481. Cheswick  and colleagues even let him in, after setting up a
  482. well-protected environment where they could watch him.  This
  483. episode is extensively described in [1].
  484.  
  485. Unfortunately, the cracker was  never  arrested.  He  should
  486. have  waited  just one year. Instead, the honor was given to
  487. two much less harmful Dutch youngsters, at the end of Febru-
  488. ary, 1992.
  489.  
  490. 7.  Second extension: booby traps.
  491.  
  492. Automatic reverse fingers had proven useful, so I decided to
  493. integrate  the  "ad  hoc"  reverse  finger tool with the tcp
  494. wrapper.  To  this  end,  the  access-control  language  was
  495. extended  so  that  arbitrary shell commands could be speci-
  496. fied.
  497.  
  498. Now that the decision to execute shell commands was based on
  499. both  the  service  and the host name, it became possible to
  500. automatically detect some  types  of  "suspicious"  traffic.
  501. For  example:  remote access to network services that should
  502. be accessed only from local systems.
  503.  
  504. Over the past months I had  noticed  several  tftp  (trivial
  505. file  transfer protocol) requests from far-away sites.  This
  506. protocol does not require any password, and it is often used
  507. for downloading systems software to diskless workstations or
  508. to dedicated network hardware.  Until a few years  ago,  the
  509. protocol  could also be used to read any file on the system.
  510. For this reason, it is still popular with crackers.
  511.  
  512. The access-control tables (fig. 9) were  set  up  such  that
  513. local  tftp  requests  would be handled in the usual manner.
  514. Remote tftp requests, however, would be refused. Instead  of
  515. the  requested  file,  a  finger  probe would be sent to the
  516. offending host.
  517.  
  518. The alarm goes off about once every two months.  The  action
  519. is  as usual: send a message to CERT and to the site contact
  520. (never to the broken-into system).
  521.  
  522.  
  523.  
  524.  
  525.  
  526.                        July 15, 1992
  527.  
  528.  
  529.  
  530.  
  531.  
  532.                            - 9 -
  533.  
  534.  
  535.  
  536.  
  537.      /etc/hosts.allow:
  538.  
  539.          in.tftpd: LOCAL, .win.tue.nl
  540.  
  541.      /etc/hosts.deny:
  542.  
  543.          in.tftpd: ALL: /usr/ucb/finger -l @%h 2>&1 | /usr/ucb/mail wswietse
  544.  
  545.      Figure 9.  Example of a booby trap on the tftp service.
  546.      The  entry  in  the first access-control file says that
  547.      tftp connections from hosts within its own  domain  are
  548.      allowed.
  549.  
  550.      The entry in the second file causes the tcp wrapper  to
  551.      perform a reverse finger in all other cases. The %h se-
  552.      quence is replaced by the actual remote host name.  The
  553.      result is sent to me by electronic mail.
  554.  
  555. This is an example of recent tftp activity:
  556.  
  557.  
  558.      Jan  4 18:58:28 svin02 tftpd: refused connect from E40-008-8.MIT.EDU
  559.      Jan  4 18:59:45 svin02 tftpd: refused connect from E40-008-8.MIT.EDU
  560.      Jan  4 19:01:02 svin02 tftpd: refused connect from E40-008-8.MIT.EDU
  561.      Jan  4 19:02:19 svin02 tftpd: refused connect from E40-008-8.MIT.EDU
  562.      Jan  4 19:03:36 svin02 tftpd: refused connect from E40-008-8.MIT.EDU
  563.      Jan  4 19:04:53 svin02 tftpd: refused connect from E40-008-8.MIT.EDU
  564.  
  565.  
  566. Due to the nature of the tftp protocol, the refused  request
  567. was  repeated every 77 seconds. The retry interval is imple-
  568. mentation dependent and can give some hints about  the  type
  569. of the remote system.
  570.  
  571. According to the reverse finger results, only one person was
  572. active  at that time: apparently, the login came from a sys-
  573. tem in France.
  574.  
  575.  
  576.      Login name: mvscott                     In real life: Mark V Scott
  577.      Office: 14S-134,  x3-6724
  578.      Directory: /mit/mvscott                 Shell: /bin/csh
  579.      On since Jan  4 12:46:44 on ttyp0 from cnam.cnam.fr
  580.      12 seconds Idle Time
  581.      No Plan.
  582.  
  583.  
  584. France told me that the cracker came from  a  NASA  terminal
  585. server (sdcds8.gsfc.nasa.gov):
  586.  
  587.  
  588.      hyper1    ttyp3    sdcds8.gsfc.nasa Sat Jan  4 17:51 - 20:47  (02:55)
  589.  
  590.  
  591.  
  592.                        July 15, 1992
  593.  
  594.  
  595.  
  596.  
  597.  
  598.                            - 10 -
  599.  
  600.  
  601. Evidently, this person liked to cross the  Atlantic  a  lot:
  602. from NASA to France, from France to MIT, and from MIT to the
  603. Netherlands.
  604.  
  605. The example in this section gives only a  limited  illustra-
  606. tion of the use of booby traps. Booby traps can be much more
  607. useful when installed on firewall systems [2], whose primary
  608. purpose  is  to  separate an organizational network from the
  609. rest of the world. A typical firewall system provides only a
  610. limited  collection  of network services to the outer world,
  611. for example:  telnet and smtp. By placing booby traps on the
  612. remaining  network  ports  one  can  implement  an effective
  613. early-warning system [1].
  614.  
  615. 8.  Conclusions.
  616.  
  617. The tcp wrapper is a simple but effective tool for  monitor-
  618. ing and controlling network activity. Our FTP logs show that
  619. it has been installed in almost every part of the world, and
  620. that it is being picked up almost every day.
  621.  
  622. To briefly recapitulate the essential features of the tool:
  623.  
  624. o    There is no need to modify existing software or  confi-
  625.      guration files.
  626.  
  627. o    The default configuration is such that the software can
  628.      be  installed "out of the box" on most UNIX implementa-
  629.      tions.
  630.  
  631. o    No impact on legal users.
  632.  
  633. o    The wrapper program does not exchange any data with the
  634.      network  client  or server process, so that the risk of
  635.      software bugs is extremely small.
  636.  
  637. o    It is suitable for both TCP (connection  oriented)  and
  638.      UDP  (datagram)  services that are covered by a central
  639.      daemon process such as the inetd.
  640.  
  641. o    Protection against hosts that pretend to  have  someone
  642.      elses  name  (name  server spoofing). This is important
  643.      for network services  such  as  rsh  and  rlogin  whose
  644.      authentication  scheme  is  based on host names. When a
  645.      host name or address mismatch is detected  the  connec-
  646.      tion  is  dropped  even before the access-control files
  647.      are consulted.
  648.  
  649. o    The optional access-control facility  can  be  used  to
  650.      shield  off open systems. Network routers can perform a
  651.      similar function, but they  seldom  keep  a  record  of
  652.      unwanted  traffic.  On  the other hand, network routers
  653.      can be useful to block access to  ports  that  normally
  654.      cannot  be  covered with wrapper-like programs, such as
  655.  
  656.  
  657.  
  658.                        July 15, 1992
  659.  
  660.  
  661.  
  662.  
  663.  
  664.                            - 11 -
  665.  
  666.  
  667.      the portmapper, NIS, NFS and X server network ports.
  668.  
  669. o    The  booby-trap  facility  can  be  used  to  implement
  670.      early-warning  systems.  This  can be especially useful
  671.      for so-called firewall computer systems that only  pro-
  672.      vide  a  limited  set  of network services to the outer
  673.      world. The remaining network ports can be  turned  into
  674.      booby traps.
  675.  
  676. Of course, the tcp wrapper is just one of the things I  have
  677. set  up  on  our  systems:  many  other trip wires have been
  678. installed as well.  Fortunately, I was able to do so  before
  679. our present system administrator was installed. In any case,
  680. Dutch crackers seem to think that the systems  at  Eindhoven
  681. University are reasonably protected.
  682.  
  683. 9.  Availability.
  684.  
  685. Several releases of the tcp wrapper source have featured  in
  686. the  USENET  comp.sources.misc  newsgroup.   The most recent
  687. version is available from:
  688.  
  689.  
  690.      ftp.uu.net:/comp.sources.misc/volumexx/log_tcp,
  691.      cert.org:/pub/tools/tcp_wrappers/tcp_wrappers.*,
  692.      ftp.win.tue.nl:/pub/security/log_tcp.shar.Z.
  693.  
  694.  
  695. 10.  About the author.
  696.  
  697. Wietse Zweitze Venema studied experimental  nuclear  physics
  698. at Groningen University. After finishing his Ph.D. disserta-
  699. tion on left-right symmetry in nuclear beta decay he  joined
  700. the  Mathematics  and  Computing  Science  department at the
  701. Eindhoven University of Technology, where he is now  a  con-
  702. sultant  at  the division of Operations Research, Statistics
  703. and Systems Theory.
  704.  
  705. 11.  References.
  706.  
  707. [1]  W.R. Cheswick, An Evening  with  Berferd,  in  Which  a
  708.      Cracker is Lured, Endured, and Studied.  Proceedings of
  709.      the Winter USENIX Conference (San  Francisco),  January
  710.      1992.
  711.  
  712. [2]  S. Carl-Mitchell, J.S.  Quarterman,  Building  Internet
  713.      Firewalls.  UnixWorld, February 1992.
  714.  
  715.  
  716.  
  717.  
  718.  
  719.  
  720.  
  721.  
  722.  
  723.  
  724.                        July 15, 1992
  725.  
  726.  
  727.